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PREFACE 


This  study  represents  the  initial  phase  of  the  Data  Reduction  and  Computer  Group’s 
(DR&CG)  effort  to  provide  a  standard  range  resource  management  and  scheduling  system 
specification  for  use  by  test  and  training  ranges.  Preliminary  to  that  effort,  an  investigation  of 
current  methods  and  systems  in  use  among  the  RCC  member  ranges  and  an  evaluation  of 
requirements  was  detennined  to  be  critical  to  the  development  of  any  future  systems  or  standards 
governing  those  systems.  This  study  was  submitted  as  RCC  task  DR-30  and  is  referred  to  herein 
by  that  name. 

This  Special  Report  is  based  upon  research  conducted  by  Ms.  Alice  Lebron,  under  the 
direction  of  Trish  Harrison,  NUWC  DIV  Newport,  AUTEC  and  a  member  of  the  DR&CG. 
Funding  was  provided  by  the  CTEIP  Program,  administered  by  the  Department  of  Defense, 
Office  of  the  Director,  Operational  Test  and  Evaluation  (DOT&E). 

The  DR&CG  welcomes  any  comments,  questions,  corrections,  additions,  or  deletions  to 
this  document.  Any  inquiries  should  be  addressed  to: 


Secretariat,  Range  Commanders  Council 

CSTE-DTC-WS-RCC 

100  Headquarters  Avenue 

White  Sands  Missile  Range,  New  Mexico  88002-5110 

Attn:  Data  Reduction  and  Computer  Group 

TELEPHONE:  (505)  678-1107 

DSN  258-1107 

EMAIL:  rcc@wsmr.army.mil 
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ACRONYMS  AND  INITIALISMS 


AFWTF 

Atlantic  Fleet  Weapons  Training  Facility 

AUTEC 

Atlantic  Undersea  Test  and  Evaluation  Center 

COTS 

commercial-off-the-shelf 

COMEX 

commence  exercise 

CTEIP 

Central  Test  and  Evaluation  Investment  Program 

DoD 

Department  of  Defense 

DR&CG 

Data  Reduction  and  Computer  Group 

FINEX 

finish  exercise 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

GPS 

Global  Positioning  System 

JON 

job  order  number 

LRP 

long  range  plan 

NUWC 

Naval  Undersea  Warfare  Center 

NAVAIR 

Naval  Air  Systems  Command 

PMRF 

Pacific  Missile  Range  Facility 

RCC 

Range  Commanders  Council 

SOAP 

simple  object  application  protocol 

XML 

extended  markup  language 
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EXECUTIVE  SUMMARY 


The  Range  Commanders  Council  (RCC),  specifically  the  Data  Reduction  and  Computing 
Group  (DR&CG),  recognized  the  need  for  an  integrated  Range  Resource  Management  and 
Scheduling  capability  that  would  facilitate  support  of  all  phases  of  test  or  training  events.  Such  a 
tool  would  span  the  initial  planning  phases,  the  execution  and  evaluation  of  an  exercise,  and 
finally,  the  accounting  and  billing  process.  Currently,  each  range  not  only  performs  its  functions 
differently,  but  the  tools,  systems,  and  steps  followed  are  also  unique  to  each  facility.  This  study 
was  initiated  with  the  goal  of  providing  the  ranges  with  a  document  describing  the  areas  to 
consider  when  designing  and  implementing  such  an  integrated  tool. 

A  three-step  approach  was  used  in  the  conduct  of  this  study.  First,  documentation  was 
solicited  from  the  different  RCC  members  who  represent  the  DoD  ranges.  Information  was 
gathered  that  focused  on  the  functionality  and  capability  of  current  range  resource  management 
and  scheduling  systems.  Interviews  with  subject  matter  experts  complemented  the  study  when 
actual  written  material  was  not  available. 

Second,  the  information  from  each  individual  range  was  analyzed,  organized,  and  then 
compared  with  the  other  ranges.  Actual  requirements  were  identified  from  systems 
documentation  or  from  interviews  and  generalized  in  order  to  present  a  broader  definition  of 
required  capabilities.  These  requirements  include  the  processes,  types  of  data,  design 
documentation,  system  architecture,  and  user  interfaces  in  current  use. 

Finally,  a  recommended  approach  for  use  in  developing  a  resource  management  and 
scheduling  tool  was  defined  that  takes  into  consideration  future  requirements  as  well  as  current 
systems  development  and  design  practices. 

The  first  phase  of  the  study  resulted  in  the  following  findings:  All  ranges  share  a 
common  definition  of  scheduling  as  the  designation  of  a  resource  or  a  sendee  to  a  specific  time 
and  event.  However,  significant  differences  were  found  in  the  actual  type  of  activities  and  tools 
that  are  used  to  manage  and  schedule  resources,  how  activities  are  perfonned,  what  tools  are 
used,  who  the  users  are,  and  finally  the  kind  of  information  that  is  administered  and  reported. 

In  terms  of  automated  systems,  the  ranges  currently  do  not  have  end-to-end  automated 
solutions  that  support  the  total  lifecycle  of  test  or  training  operations.  Frequently,  the 
instrumentation  and/or  logistical  planning  and  scheduling  are  conducted  manually  by  resource 
managers  and  test  or  training  exercise  managers. 

This  infonnation  was  used  to  develop  the  following  set  of  recommendations  to  be  used  in 
the  design  and  implementation  of  any  Range  Resource  Management  and  Scheduling  capability. 

1 .  Model  Template.  Define  a  model  template  that  will  fit  the  broad  spectrum  of  needs,  but 
which  will  also  allow  for  uniqueness  where  necessary.  Users  must  define  the  categories  and  the 
levels  of  configuration  that  would  allow  a  tool  to  be  both  expandable  in  functionality  and  flexible 
in  its  design. 
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2.  Software  Design.  Concentrate  on  configurable  software  design  and  distributed 
implementation  where  applicable.  Current  technology  allows  the  system  designer  to  build  and 
deploy  software  in  a  modular  fashion.  The  ranges  could  benefit  from  a  modular  design  in  two 
significant  ways:  (a)  by  sharing  development  and  maintenance  costs  and  (b)  by  improving  the 
ability  to  communicate  and  transfer  information  within  the  range  community. 

3.  Core  Requirements.  Create  consensus  and  detennine  what  are  the  core  requirements  that 
would  best  support  range  operations.  The  following  points  should  be  thoroughly  studied  by  all 
potential  stakeholders,  and  a  decision  should  be  made  as  to  what  levels  of  automation  and 
maintenance  jurisdiction  are  to  be  applied  when  designing  future  system  capabilities: 

a.  Resource  management  levels 

b.  Aggregation  of  assets  to  satisfy  the  requirements  of  an  event 

c.  Coordination  of  information  sharing  at  the  different  levels  of  range  management 

d.  Support  of  the  life-cycle  operations  of  a  range  event  (from  planning  &  scheduling,  to 
post-operations  support) 

e.  Support  planning  and  simulation  for  feasibility  of  range  events  and  optimization  of  range 
resource  management 

4.  Emerging  Technologies.  Investigate  the  feasibility  of  emerging  technologies  such  as: 

a.  Web  applications  such  as  Semantic  Web  that  allow  sharing  of  content  across  the  specific 
communities  while  matching  content  to  a  specific  user’s  profile.  Figure  3-3  illustrates 
how  the  ranges  could  reap  the  benefits  from  the  use  of  the  web-enabled  applications. 

b.  The  extended  Markup  Language  (XML),  which  would  help  define  multiple 
configurations  of  data  and  services 

c.  Simple  Object  Application  Protocol  (SOAP)  to  help  with  the  exchange  of  data 

5.  Management  Support.  Provide  the  right  project  management  support  with  the  right 
combination  of  technical  and  operational  direction  and  control.  The  multiple  number  of  end- 
users  for  a  Range  Resource  Management  and  Scheduling  capability  dictate  that  representatives 
of  all  functions  agree  on  the  functionality  that  would  be  provided  by  the  tool.  Furthermore,  a 
facilitator  should  be  used  during  the  design  of  the  tool  to  ensure  that  all  stakeholders’  views  are 
adequately  represented. 

6.  Design  Considerations.  Engage  in  a  phased  development  approach  that  would  foster  the 
model-test-deploy  methodology.  Develop  and  test  with  end-users  all  prototype  designs  of 
functionality  and  interfaces  early  in  the  design  stage.  With  the  rapid  changes  in  technology 
platforms  and  techniques,  it  would  be  advisable  not  to  engage  in  long-term  development  projects 
that  would  yield  results  almost  obsolete  by  the  time  they  reach  the  end-user.  It  is  recommended 
that  the  designers  and  developers  share  a  constant  awareness  of  new  developments  in  technology 
and  reflect  those  in  the  development  and  implementation  of  the  final  capability. 
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7.  Commonality  Features.  Detennine  how  commonality,  sharing  of  assets,  inter/intra  range 
operations  relate  to  the  design  and  deployment  of  future  range  systems: 

a.  Investigate  how  investment  in  new  range  systems  could  influence  commonality  of 
systems  lifecycle. 

b.  Determine  how  the  DoD  Business  Initiative  Council  and  Foundation  Initiative  2010 
relate  to  future  range  resource  and  scheduling  capabilities. 

c.  Clearly  state  where  new  common  processes  will  be  institutionalized,  where  local 
governing  procedures  will  be  followed,  and  how  it  all  fits  into  the  range  environment  of 
the  future. 
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INTRODUCTION 


1.1  Background 

The  Range  Commanders  Council  (RCC),  specifically  the  Data  Reduction  and  Computing 
Group  (DR&CG),  recognized  the  need  for  an  integrated  Range  Resource  Management  and 
Scheduling  capability  that  facilitate  the  logistics  and  execution  of  test  or  training  events  within 
the  Department  of  Defense  (DoD)  test  and  training  ranges.  These  functions  are  not  new  to  the 
DoD  ranges.  In  fact,  it  is  part  of  their  everyday  operations,  and  it  is  critical  to  accomplish  their 
mission  of  providing  our  armed  forces  with  instrumented  facilities  to  test  new  systems  or  train  in 
realistic  environments. 

A  key  component  to  ensuring  continuous  operations  is  the  management  of  range 
resources.  Providing  accurate  knowledge  of  range  resource  capabilities,  availability  status,  cost, 
as  well  as  safety,  environmental  and  other  operational  data  is  vital  to  the  effective  and  timely 
assembly  of  the  necessary  elements  to  execute  a  test  or  training  event. 

Today,  ranges  from  every  Service  conduct  air,  sea,  and  land  operations  by  following  local 
procedures  to  execute  the  same  functions  of  range  resource  management,  resource  scheduling, 
event  planning  and  cost  accounting  among  others.  Each  range  not  only  performs  these  functions 
differently,  but  the  tools,  systems,  and  steps  followed  are  also  unique  to  each  facility. 
Furthermore,  event  planning,  resource  management,  scheduling,  and  billing  functionality  are 
often  supported  by  manual  or  stand-alone  systems.  The  culture  and  uniqueness  of  the  events  that 
occur  at  each  range  facility,  as  well  as  the  ranges’  autonomy,  have  been  attributed  as  the  major 
deterrents  of  institutionalized  commonality  of  the  processes  that  govern  the  planning,  scheduling, 
and  execution  of  test  and  training  events.  While  the  overall  functional  requirements  are  very 
similar,  few  ranges  have  shared  commonality  of  processes  or  tools  when  designing,  building  or 
deploying  systems. 

The  fact  that  all  the  ranges  have  requirements  to  manage  their  resources  and  provide 
systematic  planning  and  scheduling  functions  in  support  of  their  operations  presents  a  prime 
opportunity  to  leverage  efforts  when  designing,  developing  or  deploying  their  supporting 
systems.  Moreover,  the  increasing  trend  toward  consolidating  services  and  operations  across 
ranges  and  the  assembly  of  joint  operations  to  test  or  train  new  warfare  capabilities  offer  a 
compelling  reason  to  further  study  what  areas  could  provide  either  enhanced  operational 
capabilities  or  cost  savings  by  sharing  or  reusing  processes,  tools  and  data. 

1.2  Purpose 

The  ultimate  goal  of  this  study  is  to  provide  all  ranges  with  recommendations  describing 
the  areas  to  consider  when  building  a  Range  Resource  Management  and  Scheduling  System. 
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It  is  anticipated  that  a  follow-on  task  will  be  initiated  to  further  refine  the  specific  requirements 
for  design  and  development.  Perhaps  ranges  can  leverage  funding  for  design  and  development, 
or  the  ranges  could  develop  a  capability  focusing  on  their  unique  resource  management  and 
scheduling  needs,  but  still  adhere  to  a  common  range  format  or  program.  In  so  doing,  all  ranges 
would  benefit  simply  by  the  definition  of  their  day-to-day  scheduling  and  resource  management 
needs.  Such  a  product  could  also  provide  business  metric  and  historical  data  to  all  DoD  range 
sponsors. 

1.3  Scope 

The  scope  of  this  task  is  three-fold:  (1)  to  identify  the  necessary  range  resource 
management  and  scheduling  needs  of  all  test  and  training  ranges;  (2)  to  capture  the  current  state 
and  available  methods  in  use  at  the  ranges;  and  (3)  to  review  other  business  processes  associated 
with  the  management  of  range  resources,  such  as  the  planning  and  execution  of  events  and 
billing  processes. 

1.4  Methodology 

A  three-step  approach  was  used  during  this  study.  First,  documentation  was  solicited 
from  the  different  RCC  members  who  represent  the  DoD  ranges.  Information  was  gathered  from 
those  ranges  that  chose  to  participate  focusing  on  the  functionality  or  capability  of  range  resource 
management  and  scheduling  systems.  Interviews  with  subject  matter  experts  complemented  the 
study  when  actual  written  material  was  not  available.  Second,  the  infonnation  was  analyzed, 
organized,  and  then  compared  with  the  other  ranges.  Actual  requirements  taken  from  either 
system  documentation  or  from  interviews  were  generalized  in  order  to  present  a  broader 
definition  of  the  required  capabilities  and  to  graphically  represent  the  processes,  data,  design 
documentation,  system  architecture,  and  user  interfaces.  Finally,  a  recommended  approach  was 
defined  which  took  into  consideration  the  identified  requirements  for  a  resource  management  and 
scheduling  tool,  as  well  as  current  systems  practices  and  design  features. 

1.5  Definition  of  Terms 

1.5.1  Ad-hoc:  Off-the-wall,  one-time  tailored. 

1 .5.2  Planning:  The  preparation,  coordination,  and  production  of  a  range  event,  where  event  is 
the  lowest  component  of  a  test,  mission,  operation  or  training  exercise.  Includes  all  activities 
that  are  required  to  assemble  and  execute  a  range  event. 

1 .5.3  Scheduling:  The  activities  performed  to  allocate  a  resource  to  a  particular  event  at  a 
particular  time. 

1 .5.4  Scheduling  System:  The  tool(s)  that  are  utilized  to  allocate  resources  to  a  particular  event 
at  a  particular  time. 

1 .5.5  Resource  Management:  The  activities  performed  for  the  upkeep  of  a  particular  resource, 
including  maintenance,  allocation  to  a  particular  event,  and  updated  infonnation  on  capabilities. 
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1 .5.6  Resource  Management  System:  The  tool(s)  that  are  utilized  to  maintain  all  required  data 
regarding  a  particular  resource,  including  resource  status,  allocation  to  a  particular  event,  as  well 
as  capability,  reliability  and  maintenance  data. 

1 .5.7  Execution:  Refers  to  the  phase  that  comprises  all  the  activities  performed  during  the 
actual  event,  where  event  is  the  lowest  component  of  a  test,  mission,  operation  or  training 
exercise. 

1.5.8  Closing:  Refers  to  all  the  activities  performed  in  order  to  finalize  all  required  reporting, 
accounting,  data  presentation  and  billing  for  a  range  event.  Some  ranges  see  this  function  as  part 
of  post  operations  while  others  see  it  as  the  next  phase  after  post  operations. 

1.5.9  Post  Operations  (post  ops):  Refers  to  the  activities  that  occur  after  the  execution  phase  is 
finalized.  Most  commonly  referred  to  as  the  phase  where  data  products  are  finished.  Some 
ranges  include  the  closing  operations  as  part  of  post  ops. 

1.5.10  Event:  The  lowest  component  of  a  test,  mission,  operation,  or  training  exercise. 

1 .5. 1 1  Op  Area:  Operation  area  is  an  instrumented  portion  of  a  range  where  events  are 
conducted. 

1.6  Applicable  References 

The  following  documents  were  used  in  the  research  for  this  report. 

a.  Atlantic  Fleet  Weapons  Training  Facility,  Preliminary  System  Requirements 
Specification ,  21  May  1999. 

b.  Atlantic  Fleet  Weapons  Training  Facility,  Software  User  Manual  for  the 
Replacement  Schedules  Computer  System,  15  September  2000. 

c.  Atlantic  Undersea  Test  and  Evaluation  Center,  Range  Scheduling  System  IT 
Development  Plan,  6  August  2001. 

d.  Atlantic  Undersea  Test  and  Evaluation  Center,  Range  Scheduling  System  IT  System 
Requirements  Specification,  12  February  2001. 

e.  Eglin/Edwards  Center  Scheduling  Enterprise  Software  Requirements 
Specification,  August  2001. 

f.  Naval  Air  System  Team  (Pax  River,  Pt.  Mugu  and  China  Lake)  Test 
Resource  Management  System,  Process  Description,  20  November  2000. 

g.  Naval  Air  System  Team  (Pax  River,  Pt.  Mugu  and  China  Lake),  Test 
Resource  Management  System,  Program  Support  Requirement  User 
Document,  1  March  2001. 
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h.  Naval  Air  System  Team  (Pax  River,  Pt.  Mugu  and  China  Lake),  Test 
Resource  Management  System,  System  Design  Description,  12  March  2001. 

i.  Pacific  Missile  Range  Facility,  Barking  Sands,  Range  Scheduling  System 
Users  Guide,  2000. 

j.  Pacific  Missile  Range  Facility,  Barking  Sands,  Range  Scheduling  System 
Software  Design  Document,  2000. 
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SECTION  2 


CURRENT  RANGE  CAPABILITIES 


2.1  General  Description 

2.1.1  Planning  and  Scheduling  Functions.  When  referring  to  range  business  processes,  it  is 
important  to  remember  that  the  ranges  exist  and  are  funded  to  provide  instrumentation  and 
measurements  for  test  and  evaluation  purposes,  or  to  offer  a  realistic  stage  for  the  training  of 
DoD  personnel.  Therefore,  it  is  vital  for  each  range  to  be  able  to  support  ongoing  planning  and 
scheduling  of  operations.  To  do  that,  infonnation  regarding  its  resources  and  services  has  to  be 
readily  available.  Figure  2-1  depicts  how  the  planning  and  scheduling  functions  are  part  of  the 
continuum  of  a  test  or  training  exercise  lifecycle.  Proper  planning  and  scheduling  is  critical  to 
the  successful  execution  and  management  of  test  and  training  activities.  In  this  case,  success  is 
viewed  as  the  disposition  of  range  resources  and  services  that  ensures  cost-effective,  safe, 
secured,  and  timely  range  operations. 


Aimed  at  providing  guidance  to  range  systems  managers  and  developers,  the  RCC  task 
DR-30  needed  to  first  establish  the  scope  and  definition  of  a  range  resource  management  and 
scheduling  capability  and  whether  such  definition  and  scope  were  equally  shared  across  all  the 
ranges.  What  was  found  was  that,  at  a  high-level,  all  the  ranges  shared  a  common  definition  as 
to  how  the  resource  management  and  scheduling  functions  supported  the  test  and  training 
process  lifecycle.  However,  there  were  two  key  areas  that  showed  significant  differences  as  to 
how  range  resource  management  and  scheduling  systems  have  been  developed.  One  is  how  the 
system  or  systems  support  range  business  processes,  and  the  second  is  at  what  level  the  resource 
management  and  scheduling  is  supported. 

When  the  actual  type  of  activities  and  tools  that  are  used  to  manage  and  schedule 
resources  were  reviewed,  there  were  significant  differences  in  terms  of  how  activities  are 
performed,  what  tools  are  used,  who  the  users  are,  and  finally  the  kind  of  information  that  is 
administered  and  reported.  However,  all  ranges  shared  a  common  definition  of  scheduling  as  the 
designation  of  a  resource  or  a  service  to  a  specific  time  and  event. 

On  the  other  hand,  resource  management  does  not  seem  to  have  a  commonly  shared 
definition.  Some  ranges  view  resource  management  at  the  major  resource  level,  such  as  an 
aircraft,  a  platform,  or  an  operational  area.  These  mission-area  range  resources  are  the  ones  that 
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would  be  scheduled,  and  their  availability  is  the  piece  of  data  that  is  most  commonly  tracked  by 
the  scheduling  and  management  systems.  All  other  resource  information  is  usually  tracked  either 
manually  by  the  resource  manager  or  by  other  stand-alone  systems.  The  kind  of  information 
managed  for  each  resource  also  varies  from  range  to  range  and  often  differs  by  the  type  of 
resource  or  the  manager  in  charge.  Some  of  the  systems  track  resource  utilization,  costs,  as  well 
as  other  miscellaneous  information  such  as  maintenance  status  or  any  dependencies  with  other 
resources. 

2.1.2  Use  of  Automation  for  Scheduling  and  Resource  Management 

Figure  2-2  shows  where  automation  is  most  commonly  used  today.  Planning  often 
consists  of  long-range,  scenario  simulation  and  development,  or  actual  event  arrangement.  At 
this  stage,  test  or  exercise  managers,  as  well  as  schedulers,  work  together  to  plan  and  schedule 
the  events  and  resources  required  to  support  range  operations.  This  is  a  complex  process  that 
often  takes  up  to  a  year  to  complete  and  frequently  is  not  final  until  days  before  the  actual  events 
are  scheduled  to  take  place. 


Scenario 

Simulation 


Most  Common 
Set  of  Processes 
Supported  Today  as 
part  of  a  “Resource 
Management  & 
Scheduling  System” 


Test/ 
Exercise/ 
Operation/  Event 
Planning 


Planning 

(Define 

Requirements) 


Scheduling 


Manual  Support 
Of  Operations  or  Ad- 
hoc  automated  tools 
used  during  these 
phases 


Execution/ 

Management 


Closing 

(Post  Ops,  Billing. 
Archive) 


Figure  2-2.  Current  system  support  for  test  and  training  operations  lifecycle. 


Current  automation  falls  short  at  most  of  the  ranges  in  the  areas  of  execution  and  closing 
of  the  operations.  There  is  minimal  integrated  automation  that  takes  into  consideration  other 
data  elements  such  as  resource  utilization,  costs,  and  billing  associated  with  each  resource  or  set 
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of  resources.  It  is  common  to  gather  data  manually  from  test  conductors  or  resource  managers  in 
order  to  determine  actual  utilization  for  management  or  billing  purposes.  It  is  not  uncommon  to 
find  schedule  infonnation  in  bulletin  boards,  spreadsheets,  off-the-shelf  calendar  programs,  or 
simply  by  statements  made  during  daily  or  weekly  briefings. 

Currently,  ranges  do  not  have  end-to-end  automated  solutions  that  support  the  total 
lifecycle  of  test  or  training  operations.  However,  during  the  time  this  study  was  being 
conducted,  several  ranges  started  to  design  more  robust  systems  that  would  integrate  automation 
and  support  the  complete  lifecycle. 

As  mentioned  earlier,  the  levels  of  scheduling  supported  by  automation  vary  from  range 
to  range.  Some  ranges  schedule  only  major  range  resources  (platforms,  range  operational  areas, 
tracking  systems).  All  the  instrumentation  or  logistical  planning  and  scheduling  is  conducted 
manually  by  the  resource  managers  and  test  or  training  exercise  managers. 

Figure  2-3  depicts  the  different  levels  of  resources  or  services  and  how  these  are 
incorporated  into  current  resource  management  and  scheduling  systems.  Note  that  the  lower  the 
level  is,  the  least  automation  there  is  and  the  more  likely  operations  will  be  supported  by  manual 
or  stand-alone  tools. 


Levels  of  Resources  and  Services 


Some  integration  of  planning,  asset  Manual  or  stove-piped  tools  are  used  at 

management  and  scheduling  processes  these  levels.  Most  information  is  shared 

and  tools  could  be  found  at  these  levels.  via  manual  (fax,  phone,  email)  means. 


Very  limited  to  no  integration  of  planning,  asset  management  and 
scheduling  processes  and  tools  could  be  found  at  all  levels. 


Figure  2-3.  Current  levels  of  planning  and  scheduling. 
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The  lack  of  integration  and  automation  is  offset  in  most  cases  by  the  vast  knowledge  and 
experience  of  range  personnel.  Even  though  this  is  a  testament  of  the  ranges’  ability  to  support 
operations,  it  is  an  area  of  concern  as  there  is  a  potential  for  errors  due  to  manual  tracking  and 
lack  of  checks  and  balances.  In  addition,  personnel  reduction,  attrition  and  turnover  are  factors 
that  highlight  the  vulnerability  of  the  balance  that  is  achieved  today  at  the  ranges.  These  factors 
further  accentuate  the  need  for  a  more  robust,  integrated  solution  that  supports  the  end-to-end 
process. 

2.2  Business  Process  View 


The  various  Resource  Management  and  Scheduling  Systems  in  current  use  generally 
follow  the  same  high-level  business  process  model  depicted  in  Figure  2-4.  As  the  flowchart 
indicates,  these  systems  gather  input  data  from  the  end  user  and  use  pre-defined  business  rules  to 
develop  a  schedule  or  a  plan  depending  on  the  output  that  has  been  programmed. 


Inputs: 

•Date(s) 

r 

•Resource  Data 

_ 1 

•Allocation  Data 

•  Other  Data 

L 

Resource  & 
Scheduling 
Management 
Process 


•  Allocation  Data  =  Association 
to  a  particular  operation/event 

•  Other  Data  =  Test  #,  JON, 
Sponsor,  Altitude,  etc. 


Defined 
Business  Rules 
&  Users 


Outputs: 

•Scheduled  Resources 
•Published  Schedule 
•Conflict  Report 


Figure  2-4.  Resource  and  scheduling  management  process  (high-level  view). 


2.3  User  Characteristics 


Table  2-1  shows  the  types  of  users  who  interact  with  the  resource  management  and 
scheduling  capabilities.  These  were  consistent  across  all  the  ranges  surveyed.  However,  as 
mentioned  previously,  many  of  the  supported  functions  are  not  automated.  For  example,  at  some 
ranges,  the  range  operations  personnel  would  find  out  about  the  schedule  from  a  test  conductor 
or  via  a  printed  version  of  the  schedule. 
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Table  2-1.  User  Population 

Type  of  User 

Create/Edit 

View 

Maintain 

Scheduling  Personnel 

0 

0 

0 

Resource/Resource 

Managers 

0 

0 

Program  Managers 

0 

0 

0 

Range  Managers 

0 

Range  Operations  Personnel 

0 

0 

Test  Conductors 

0 

0 

System  Developers 

0 

0 

Range  Users 

0 

System  Administrators 

0 

0 

0 

2.4  Data  Inputs 

2.4. 1  Types  of  Data.  There  are  three  major  data  types  that  relate  to  resource  management  and 
scheduling  as  depicted  in  Table  2-2.  Resource,  allocation  and  other  data  comprise  the  bulk  of 
the  data  elements  required  by  a  resource  management  and  scheduling  system.  Resource  data 
contains  all  the  data  attributes  of  a  particular  resource  and  is  often  maintained  by  the  resource 
manager.  Allocation  data  pertains  to  the  particulars  of  the  test,  training  or  any  other  event  for 
which  a  particular  resource  could  be  allocated.  Allocation  data  is  often  entered  into  the  system 
by  scheduling  personnel.  Other  data  refers  to  any  additional  data  elements  that  are  captured  by 
the  system.  This  classification  is  where  all  the  ranges  have  developed  a  significant  number  of 
unique  data  requirements. 


T able  2-2.  Sample  of  Data  Inputs 

Resource  Data 

Allocation  Data 

Other  Data 

Name 

Test/Exercise  # 

Test/Operation/Event  Data 

Number  or  ID 

Test/Exercise  Type 

Reliability  Data 

Description 

Date  (COMEX/FINEX) 

Job/Operation/Test  Number 

Dependencies 

Sponsor 

S  equenc  e/Planning 

Restrictions 

Project  Manager 

Remarks/Notes 

Location 

Test/Training  Engineer 

Announcements 

Owner 

Operational  Area 

Warnings 

Status 

Customer 

Priority 
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2.4.2  Factors  Affecting  Choices  of  Data  Elements.  The  number  of  data  elements  that  are 
required,  the  mechanisms  and  the  type  of  input  data  also  varied  from  system  to  system.  As  was 
mentioned  earlier  in  this  document,  the  level  of  planning  and  scheduling,  as  well  as  the  type  of 
processes  supported,  dictate  what  kind  of  input  data  is  required.  A  significant  difference  was 
also  found  in  how  the  ranges  chose  to  combine  sets  of  data  into  templates  or  profiles.  The 
following  three  key  areas  were  observed  as  drivers  for  the  differences  in  data  inputs. 

a.  The  level  of  scheduling  supported: 

•  Is  the  process  driven  by  test,  exercise,  operation  or  event-type  dependency?  Are 
requirements  nested? 

•  Are  there  any  templates/profiles  already  programmed/configured  that  contain  the  bulk  of 
the  required  data? 

b.  The  desired  output: 

•  Range/resource  or  long  range  schedule 

•  Operations  area  schedule 

•  Resource  management  reporting 

•  Resource  utilization  reporting 

•  Resource  availability 

•  Scenario  generation 

•  Template  generation 

c.  The  interfaces  to  other  systems  or  additional  processes  supported: 

•  Cost  estimation 

•  Billing 

•  Resource  utilization 

•  Approval  workflow 
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2.5  Form  of  Data  Outputs 


The  type  of  outputs,  as  well  as  the  delivery  format,  also  varied  from  system  to  system. 
How  reports  are  developed  and  processed  depends  on  the  sophistication  of  the  reporting  tools 
used.  The  following  list  shows  the  most  prominent  requirements  for  output  generation. 

•  On-line  and  printed  forms 

•  Standard/dynamic  query  support 

•  Email/fax/  notification  capabilities 

•  Graphic  timeline  presentation  for  water,  space,  and  operation  areas 

•  Interfaces  to  other  systems/applications  such  as  billing,  cost  estimates,  resource 
utilization,  and  outages/maintenance 

2.6  High-Level  Functional  Requirements 

One  of  the  most  prominent  differences  found  for  each  of  the  systems  reviewed  was  the 
way  functional  requirements  were  documented.  As  indicated  in  Table  2-3,  scheduling  is  a 
function  that  is  provided  by  all  these  systems  while  resource  management,  planning  or  other 
support  functions  are  not  available  at  all  ranges. 


Table  2-3. 

High-Level  Functional  Requirements  Comparison  from  Available 
Systems  Documentation 

AFWTF 

AUTEC 

Eglin/Edwards 

NAVAIR 

PMRF 

•  Request  a 

•  Manage 

•  Request  a 

•  Test  Program 

•  Schedule 

Long 

Test 

Mission 

Resource 

-Exercise 

Range 

Planning 

-Operations 

Event 

•  Schedule 

•  Manage  a 

-Resources 

Test 

Mission 

•  Test  Cost 

•  Schedule 

(lifecycle) 

Estimating 

•  Manage  Details 

Event 

•  Schedule 

n 

-Cost 

Test 

•  Schedule  a 

•  Range 

-Approvals 

•  Report 

Range 

Mission 

-Billing 

Conflicts 

Resources 

-Post  Ops 

•  Manage  a 

•  Resource 

Manage 

•  Report 

Mission 

Utilization 

Templates 

Conflicts 

Profile 

Reporting 

•  Support  a 

•  Interface  with 

Mission 

NAVAIR 

Financial 

System 
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2.7  Detailed  Functional  Capabilities 


Table  2-4  contains  a  detailed  listing  of  the  capabilities  that  are  supported  at  the  different 
ranges.  These  are  categorized  by  the  occurrence  of  automated  applications.  It  was  clear  that 
these  capabilities  are  accomplished  and,  therefore,  represent  a  requirement  to  support  current 
range  operations.  Note  that  the  degree  of  integrated  automation  is  significantly  different  across 
all  facilities. 


Table  2-4.  Current  Functionality  Requirements  to  Support  Range  Operations 

Number 

Description 

[For  comparison  purposes,  the  functionality  descriptions  are 
presented  in  a  generic  form  where  appropriate] 

Automated  Occurrence 
***  =  All  Ranges 
**  =  Most  Ranges 

*  =  Few  Ranges 

1.0 

Planning 

1.1 

Support  long-range  planning  (LRP)  allowing  simulation  of 
future  range  operations 

* 

1.2 

Provide  the  functionality  of  converting  LRPs  into  test, 
mission,  operation  or  event  requests 

* 

1.3 

Provide  the  functionality  to  create,  delete,  store  and  edit  a  test, 
mission,  operation  or  event  LRP 

* 

1.4 

Provide  the  functionality  to  authorize  and  de-authorize  test, 
mission,  operation  or  event  LRP 

* 

1.5 

Provide  the  functionality  to  view,  copy,  and  pick  from  a  list  of 
test,  mission,  operation,  event  LRP 

* 

1.6 

Provide  the  functionality  of  routing  the  test,  mission, 
operation  or  event  LRP  for  approval,  view,  notification  to  a 
select  pre-defmed  population  via  electronic  means 

* 

1.7 

Provide  the  functionality  to  enable  a  select  population  to  view 
or  edit  a  test,  mission,  operation  or  event  LRP 

* 

1.8 

Provide  a  means  by  which  test  or  training  planners  can  build  a 
detailed  test,  mission,  operation  or  event  request  and  then 
submit  for  further  management  or  scheduling 

** 

1.9 

Provide  the  functionality  to  create,  delete,  store  and  edit  a  test, 
mission,  operation  or  event  request 

** 

1.10 

Provide  the  functionality  to  authorize  and  de-authorize  test, 
mission,  operation  or  event  request 

** 

1.11 

Provide  the  functionality  to  view,  copy,  and  pick  from  a  list  of 
test,  mission,  operation,  or  event  requests 

** 

1.12 

Provide  the  functionality  of  routing  the  test,  mission, 
operation  or  event  request  for  approval,  view,  notification  to  a 
select  pre-defmed  population  via  electronic  means 

** 

1.13 

Provide  the  functionality  to  enable  a  select  population  to  view 
or  edit  a  test,  mission,  operation  or  event  request 

** 
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Table  2-4.  Current  Functionality  Requirements  to  Support  Range  Operations 

Number 

Description 

[For  comparison  purposes,  the  functionality  descriptions  are 
presented  in  a  generic  form  where  appropriate] 

Automated  Occurrence 
***  =  All  Ranges 
**  =  Most  Ranges 

*  =  Few  Ranges 

1.14 

Provide  a  means  by  which  test  or  training  planners  can  build  a 
detailed  test,  mission,  operation  or  event  template  that 
contains  particular  details  related  to  the  specific  requirements 
of  a  test,  mission,  operation  or  event.  For  example:  for  a 
particular  event,  there  are  warnings,  altitude,  specific 
resources,  as  well  as  environmental  and  safety  requirements 

** 

1.15 

Provide  the  functionality  to  create,  delete,  store  and  edit  a  test, 
mission,  operation  or  event  template 

** 

1.16 

Provide  the  functionality  to  authorize  and  de-authorize  a  test, 
mission,  operation  or  event  template 

** 

1.17 

Provide  the  functionality  to  view,  copy,  and  pick  from  a  list  of 
test,  mission,  operation,  or  event  templates 

** 

1.18 

Provide  the  functionality  of  routing  the  test,  mission, 
operation  or  event  template  for  approval,  view,  notification  to 
a  select  pre-defined  population  via  electronic  means 

** 

1.19 

Provide  the  functionality  to  enable  a  select  population  to  view 
or  edit  a  test,  mission,  operation  or  event  template 

** 

1.20 

Provide  the  functionality  to  request  and  manage  a 
job/test/exercise/operation  number 

** 

1.21 

Provide  the  functionality  to  create,  delete,  store  and  edit  a 
job/test/exercise/operation  number 

** 

1.22 

Provide  the  functionality  to  view,  copy,  and  pick  from  a  list  of 
job/test/exercise/operation  numbers 

** 

1.23 

Provide  the  functionality  of  routing  the  job/test/exercise/ 
operation  number  for  approval,  view,  and  notification  to  a 
select  pre-defined  population  via  electronic  means 

** 

1.24 

Provide  the  functionality  to  configure  platforms  such  as 
aircraft,  vehicles,  and  submarines  to  be  used  as  resources 
during  a  test,  mission,  operation  or  event 

* 

1.25 

Provide  the  functionality  to  create,  delete,  store  and  edit  a 
platform  configuration 

* 

1.26 

Provide  the  functionality  to  view,  copy,  and  pick  from  a  list  of 
platform  configurations 

* 

1.27 

Provide  the  functionality  of  routing  the  platform  configuration 
for  approval,  view,  and  notification  to  a  select  pre-defined 
population  via  electronic  means 

* 

1.28 

Provide  the  functionality  to  use  a  validation  criteria  and 
method  for  templates,  configurations,  plans  and  requests 

* 

1.29 

Provide  the  functionality  to  create,  delete,  edit  and  store 
validation  criteria  for  templates,  configurations,  plans  and 
requests 

* 
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Table  2-4.  Current  Functionality  Requirements  to  Support  Range  Operations 

Number 

Description 

[For  comparison  purposes,  the  functionality  descriptions  are 
presented  in  a  generic  form  where  appropriate] 

Automated  Occurrence 
***  =  All  Ranges 
**  =  Most  Ranges 

*  =  Few  Ranges 

1.30 

Provide  capabilities  to  create  management  reports  containing 
information  related  to  LRPs,  plans,  templates,  requests, 
validation,  and  configurations 

* 

1.31 

Provide  the  functionality  to  create  individual  or  consolidated 
reports  related  to  LRPs,  plans,  templates,  requests,  validation, 
and  configurations 

* 

1.32 

Provide  the  functionality  to  view  availability  of  select 
resources  based  on  a  defined  date 

** 

1.33 

Provide  the  functionality  to  create  a  cost  estimate  based  on  the 
test,  mission,  operation  or  event  plan 

* 

2.0 

Management 

2.1 

Provide  the  functionality  to  track  all  modifications  by  user 

** 

2.2 

Provide  the  functionality  to  change  the  status  of  a  test, 
mission,  operation  or  event 

** 

2.3 

Provide  the  functionality  to  manage  a  list  of  status  elements 
such  as  pre-planning,  schedule  requested,  in-progress, 
cancelled  and  closed 

** 

2.4 

Provide  the  functionality  to  notify  of  a  change  of  status  to  a 
select  pre-defined  population  via  electronic  means 

* 

2.5 

Provide  the  functionality  to  approve,  view,  list  a  select  number 
of  tests,  missions,  operations  or  events  to  a  consolidated  group 

* 

2.6 

Provide  the  functionality  to  create  management  reports  related 
to  the  management,  status,  tracking  of  tests,  missions, 
operations  or  events 

** 

2.7 

Provide  the  functionality  to  track  resource  usage 

* 

2.8 

Provide  the  functionality  to  report  on  selected  or  grouped 
usage  of  range  resources 

* 

2.9 

Provide  the  functionality  to  review  and  approve  actual  costs 

* 

2.10 

Provide  the  functionality  to  consolidate  billing  data  and  create 
billing  reports 

* 

2.11 

Provide  the  functionality  to  track  all  modifications  by  user 

** 

2.12 

Provide  the  functionality  to  create,  edit,  delete  and  report  on 
test,  exercise,  operation  or  event  order  to  be  used  by  contract 
or  range  personnel  to  further  assign  secondary  resources  and 
execution  activities 

** 
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Table  2-4.  Current  Functionality  Requirements  to  Support  Range  Operations 

Number 

Description 

[For  comparison  purposes,  the  functionality  descriptions  are 
presented  in  a  generic  form  where  appropriate] 

Automated  Occurrence 
***  =  All  Ranges 
**  =  Most  Ranges 

*  =  Few  Ranges 

2.13 

Provide  the  functionality  of  routing  the  test,  exercise, 
operation  or  event  order  for  approval,  viewing,  and 
notification  to  a  select,  pre-defmed  population  via  electronic 
means 

* 

2.14 

Provide  the  functionality  to  manage  priority  assignment  based 
on  predefined  criteria 

* 

3.0 

Scheduling 

3.1 

Support  the  functionality  to  schedule  resources  based  on 
predefined  constraints  such  as  priority,  environmental,  safety, 
blackouts,  labor,  and  resource  status 

* 

3.2 

Support  the  functionality  to  aggregate  scheduling 
requirements  based  on  predefined  templates  or  profiles 

* 

3.3 

Support  the  functionality  to  de-conflict  schedules 
automatically 

* 

3.4 

Support  the  functionality  to  report  schedule  conflicts  for 
manual  de-confliction 

3.5 

Provide  the  functionality  to  report  a  range  schedule  on  a  pre- 
defmed  time  frequency  such  as  daily,  weekly,  monthly, 
quarterly  or  yearly 

*** 

3.6 

Provide  the  functionality  to  report  a  schedule  for  a  particular 
set  of  resources,  or  for  a  test,  exercise,  operation  or  event,  or 
for  a  particular  operation  area 

*** 

3.7 

Provide  the  functionality  to  report  on  status  of  a  scheduled 
test,  exercise,  operation  or  event 

3.8 

Provide  the  functionality  to  schedule  a  test,  exercise,  operation 
or  event  individually  or  as  a  batch  or  group 

** 

3.9 

Provide  the  functionality  to  change  the  schedule 

3.10 

Provide  the  functionality  to  track  all  modifications  by  user 

*** 

3.11 

Provide  the  functionality  to  create  and  modify  scheduling 
constraints  for  range  resources 

* 

3.12 

Provide  the  functionality  to  notify  of  a  creation  or  change  in 
the  schedule  to  a  select,  pre-defmed  population  via  electronic 
means 

=1= 

3.13 

Provide  the  functionality  to  create  scheduling  management 
reports 

*** 

3.14 

Provide  the  functionality  to  report  on  reasons  for  non¬ 
scheduling 

* 

3.15 

Provide  the  functionality  to  produce  a  report  of  available 
resources,  frequencies,  sites  or  operation  areas 

** 
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Table  2-4.  Current  Functionality  Requirements  to  Support  Range  Operations 

Number 

Description 

[For  comparison  purposes,  the  functionality  descriptions  are 
presented  in  a  generic  form  where  appropriate] 

Automated  Occurrence 
***  =  All  Ranges 
**  =  Most  Ranges 

*  =  Few  Ranges 

3.16 

Provide  the  functionality  to  produce  a  report  of  scheduled 
resources,  frequencies,  sites  or  operation  areas  for  a  specific 
time 

** 

3.17 

Provide  the  functionality  to  allow  multiple  layers  of  security 
for  creation,  editing,  deletion  and  viewing  of  the  scheduling 
functionality 

** 

4.0 

Resource  Management 

4.1 

Provide  the  functionality  to  manage  the  information  on 
resources  based  on  predefined  resource  templates  such  as 
changing  available  status,  location,  or  owner 

** 

4.2 

Provide  the  functionality  to  create,  edit,  delete,  store  and  view 
a  resource  template  (a  resource  could  be  a  range  resource  or  a 
platform  provided  by  the  range  user) 

** 

4.3 

Provide  the  functionality  to  report  on  resource  utilization, 
status,  or  detailed  resource  information 

* 

5.0 

Support 

5.1 

Provide  the  functionality  to  manage  end-user  information 

5.2 

Provide  the  functionality  to  manage  electronic  mail  lists 

** 

5.3 

Provide  the  functionality  to  manage  communication  protocols 
of  automated  messages  such  as  news,  notification  of  schedule 
changes,  requests  for  approval,  etc. 

** 

5.4 

Provide  the  functionality  to  manage  tracking  instrumentation 
information  (such  as  a  hydrophone  or  a  radar) 

* 

5.5 

Provide  the  functionality  to  manage  beacon  information 

* 

5.6 

Provide  the  functionality  to  manage  pod  information 

* 

5.7 

Provide  the  functionality  to  manage  munitions  information 

* 

5.8 

Provide  the  functionality  to  manage  auxiliary 
systems/communications  information 

* 

5.9 

Provide  the  functionality  to  manage  frequency  information 

* 

5.10 

Provide  the  functionality  to  manage  control  facility 
information 

* 

5.11 

Provide  the  functionality  to  manage  air/surface/subsurface 
space  information 

* 
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2.8  Systems  Architecture 

The  following  list  summarizes  the  most  significant  findings  from  the  analysis  of  the 
system  architecture  documentation  provided  by  the  ranges.  The  system  architectures: 

•  Vary  from  range  to  range, 

•  Were  stand-alone  or  integrated  to  the  Enterprise  Systems, 

•  Were  predominantly  client-server  and  multi-tiered  approaches, 

•  Have  a  current  requirement  for  web-enabled  technology, 

•  Use  predominantly  commercial-off-the-shelf  (COTS)  technology  across  all  ranges  for 
hardware,  databases,  and  reporting  tools 

2.9  System  Documentation 

•  Limited  documentation  is  available  -  ad-hoc  development  of  systems  has  been  the 
nonn.  Process,  system  requirements,  system  design  documentation  was  not  readily 
available  at  the  majority  of  the  ranges  surveyed.  What  documentation  is  available  is  at 
different  levels  of  detail.  Some  of  the  documents  are  process-specific,  while  others 
are  detailed  enough  to  show  inputs,  outputs,  and  processing  supported  by  the  system 
capabilities. 

•  Some  use  standards  for  the  requirements  gathering,  design,  or  development  phases  of 
scheduling  systems.  IEEE  standards  were  used  by  some  of  the  ranges  for  the 
documentation  of  their  system  requirements  and  design.Most  of  the  system 
documentation  available  corresponds  to  recent  (last  three  years)  or  planned,  ad-hoc 
scheduling  system  development. 

2.10  User  Interface:  The  Look  and  Feel 


As  is  depicted  by  Figures  2-5  through  2-7,  the  user  interfaces  implemented  by  these 
ranges  differ  considerably  in  terms  of  configuration  and  also  in  terms  of  what  data  is  presented 
and  managed.  No  consistent  standards  or  guidelines  were  found  to  be  in  use  by  any  of  the 
ranges. 
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Figure  2-5.  PMRF  user  interface. 
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Figure  2-6.  AFWTF  user  interface. 
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PACIFIC  RANGES  &  FACILITIES  PROGRAM  SUPPORT  REQUIREMENT 
Sea  Range  (Production) 


PSR  TITLE:  THIS  IS  A  TEST  PSR 


Lead  Range  SR  Facility  ID:  SR  PSR  Num:  96  Hazard  Flag:  L 


TEST  MANAGER:  usa 

Carl  Flynn 


PHONE: 

COM:  805-989-3812 
DSN:  351-3812 


CODE: 

529800E 


PROJECT  CONTACT:  ms 
Joe  Customer 


MAILING  ADDRESS: 
12345  Main  Street 

Anywhere,  CA 

99879 


PHONE: 
COM: 
DSN: 


555-555- 

9999 

None 


CODE: 

Company 


TEST  DESCRIPTION:  BED  MAJOR  PROGRAM  ID:  FLEET  TRAINING 
TEST  TYPE  A/D  TEST  PHASE:  B 

Up  to  500  characters  of  comments  may  be  entered. 


SUB  ID:  SLAM 
ITEM  TESTED: AD 


RANGE  ASSETS  UTILIZED:  ess 
GPS  RADAR 

TM 

OTHER:  Up  to  20  characters 


TEST  BAYS 


SAFETY  APPROVALS:  ms 
B  Laser  used 

□  Radiation  Hazard 
B  Safety  Waiver  Rqd 

□  Weapon  Hazard  Pattern  Rqd 
B  Laser  Hazard  Pattern  Rqd 

Toxic  Hazard  Requirements: 

Up  to  200  characters  may  be  entered 


RS A  #  016  063  097  1 26  ESA  #  021  1 02E/1 090C  1 09BC  180 

RS0  Plan  #:  1-89  164  014/157  164  2-91 

Environ  Approval  #:  435566 

FUZE  Type:Up  to  50  characters  may  be  entered. 


Justification  for  Use  of  Energetic  Materials: 

Up  to  200  characters  may  be  entered 

Applicable  Energetic  Material  Data  Sheets: 

Up  to  200  characters  may  be  entered 

Remarks:Up  to  100  characters  may  be  entered. _ 

AIRSPACE  REQUIRED:  bed  GROUND  RANGE  REQUIRED: 

3D _ Cl  177  M5 _ R2509 _ 00 _ IS  3F  6C  Cl  177 

TYPE  OF  AIRCRAFT:  ms  TYPE  OF  TARGET 

DRONE  REMOTE  MANNED 

CP  IC  F-15E  50FTS  AERJEL  4FTS  A- 6 

AZTEC  HARM  HARPOON  BARGE  B-l  F-15E 

OTHER: Up  to  20  characters. OTHER: Up  to  100  characters. 


TYPE  OF  ORDNANCES 

INERT 

FUZED 

HE 

PYRO 

009ALPM 

B 

□ 

B 

□ 

01BMAGS 

□ 

B 

□ 

B 

01BMAGS 

B 

□ 

□ 

□ 

OTHER  Up  to  20  characters 


TEST  MANAGEMENT  OPS  CONTROL/SURFACE  OPS/TRACK  OPS  RANGE  SCHEDULING  DATE  ISSUED 


Figure  2-7.  NAVAIR  user  interface. 


2,11  Hardware/Software  Interfaces 


Limited  interfaces  to  other  systems  are  currently  in  place.  Most  of  the  Resource 
Management  and  Scheduling  Systems  are  stand-alone.  One  significant  deviation  from  this  trend 
is  the  planned  Eglin-Edwards  Center  Scheduling  Enterprise  System.  This  system  will  be  used  by 
both  Eglin  and  Edwards  AFB  facilities.  It  will  have  at  least  twelve  different  software  interfaces, 
which  will  include  links  to  their  Earned  Value  Cost  Analysis,  Historical  File  Mission  and 
Resources,  and  to  their  Military  Airspace  Management  systems.  Other  ranges  such  as  AFWTF 
do  not  have  any  interfaces  to  other  systems.  As  mentioned  earlier,  interfaces  to  other  systems  are 
a  function  of  what  kinds  of  business  processes  are  supported,  at  what  level,  and  what  kind  of 
automation  exists  at  the  particular  range. 
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2.12  Implementation  Drivers 


The  following  list  contains  the  factors  that  were  consistently  found  to  be  critical  when 
developing  Range  Resource  Management  and  Scheduling  systems.  No  apparent  priority  or 
weighting  was  found  to  influence  a  particular  design  for  any  of  the  range  systems  analyzed. 

•  User  requirements 

•  Physical  location 

•  Type  of  events  supported 

•  Security  levels 

•  Remote  access 

•  Number  of  users 

•  Process  supported 

•  Levels  of  scheduling  complexity 

•  Technology 

•  Budget 

•  Business  rules 

•  Communication  requirements 

•  Latency  requirements 

•  Reporting  requirements 

•  Interface  requirements 

•  Data  management  requirements  -  archival  of  historical  data 

2.13  Summary  of  Findings 

Current  Resource  Management  and  Scheduling  Systems  have  the  following  characteristics: 

a.  Although  viewed  as  mission  critical  functions,  scheduling  and  resource  management  are 
still  highly  labor  intensive,  manual  processes. 

b.  Automation  is  not  widespread  across  the  lifecycle  of  test  or  training  exercises. 

c.  Not  all  resource  management  and  scheduling  functions  are  perfonned  by  the  same 
system.  Scheduling  is  more  commonly  automated  than  resource  management. 

d.  The  business  processes  that  are  supported  by  automation  vary  from  range  to  range. 

Figure  2-8  depicts  how  the  range  systems  support  their  operations.  There  are  three  key 
points  to  note.  First,  all  ranges  perform  very  similar  functions  in  support  of  their 
operations.  Second,  they  do  it  their  own  way  -  some  methods  are  circles  and  others  are 
squares.  Third,  as  the  lines  indicate,  any  information  or  communication  that  is  exchanged 
between  functional  areas  is  not  integrated.  Therefore,  the  risks  of  communication  errors, 
duplication  of  effort,  and  maintenance  costs  increase  proportionally  to  the  number  of 
users  and  stand-alone  systems. 
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Inter- 
Range 
Commu¬ 
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is  done 
via  ad- 
hoc 

methods 


Range  B 

Operations/Mission 

Execution 


Logistics 

Management 


While  both  Ranges  perform  the  same  functions,  each  has  their  own  distinct  supporting  methods  and  tools.  Stand  - 
alone  systems  increase  the  efforts  dedicated  to  exchange  and  communicate  information  as  well  as  increase  the  risks  of 
communication  errors,  duplication  of  effort  and  systems  development  and  maintenance  costs. 


_ Lines  represent  information  exchange 


Figure  2-8.  A  conceptual  view  of  current  range  operations. 


e.  The  implementation  of  the  systems  studied  varied  depending  on  the  type  of  processes 
supported  and  the  level  at  which  resource  management  and  scheduling  was  conducted. 

f.  Automated  de-confliction  of  scheduling  is  not  a  common  function  currently  supported. 
At  some  ranges,  automation  of  scheduling  processes  still  remains  as  a  documented 
calendar  of  events,  and  conflict  resolution  is  a  manual  function. 

g.  Requirements  at  a  high  level  are  the  same  for  all  ranges.  The  differences  found  in  the 
development  and  implementation  deal  with  how  business  processes  are  supported,  and 
what  attributes  are  required  by  each  range  facility. 

h.  There  is  significant  opportunity  to  leverage  system  development  dollars  if  a  common 
design  schema  is  used  to  document  and  design  resource  management  and  scheduling 
systems. 

i.  Significant  thrust  is  in  place  to  offer  enterprise-wide  systems  and  to  share  common  tools 
for  resource  management  and  scheduling. 


2-17 


SECTION  3 


RECOMMENDATIONS 


3.1  Recommended  Concept 

As  depicted  in  Figure  3-1,  one  recommendation  is  to  consolidate  system  or  tools 
functionality  to  support  multiple  range  functions.  This  type  of  combined  or  integrated  capability 
has  been  a  focus  for  some  of  the  ranges  and  is  slowly  gaining  momentum  as  more  ranges  are 
defining  their  business  processes  in  terms  of  an  enterprise  model.  This  is  evident  in  the  Air 
Force’s  Eglin/Edwards  Center  Scheduling  Enterprise  Software  Requirements  Specification  as 
well  as  in  the  NAVAIR  Test  Resource  Management  System  Design  Description.  Combining 
functionality  of  the  tools  and  the  management  of  data  in  a  single  repository  that  is  used  by 
multiple  applications  ensures  data  integrity,  minimizes  development  and  maintenance  costs,  and 
fosters  commonality  of  services. 

The  benefit  of  commonality  across  the  ranges  is  not  easily  achieved  with  this  scenario 
since,  while  it  consolidates  functions,  it  does  so  within  the  doctrine  and  procedures  of  a 
particular  range.  However,  if  we  take  this  same  concept  and  provide  the  ability  for  a  range  to 
predefine  the  data  and  business  rules  in  a  template  that  then  could  be  translated  into  a  common 
repository  of  data  elements  and  business  rules,  then  the  benefits  would  transcend  a  particular 
range,  and  the  vision  of  commonality  could  very  well  become  a  reality. 


Inter- 
Range 
Commu¬ 
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is  done 
via  ad- 
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methods 


While  both  Ranges  perform  the  same  functions,  each  has  one  inte  grated  tool  supporting  the  Planning,  Scheduling, 
Resource  Management  and  Billing  functions  creating  efficiencies  in  information  management  and  reducing  the  risks 
associated  with  supporting  stand  -alone  systems. 

Lines  represent  information  exchange 


Figure  3-1 .  A  conceptual  view  of  range  operations  supported  by  integrated 
tools  but  developed  to  support  a  single  range. 
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The  integrated  tool  shown  in  Figure  3-2  provides  the  translation  vehicle  to  enable  a 
system  to  be  configured  to  support  local  and  range-specific  language,  their  own  “look  and  feel,” 
and  their  associated  business  rules,  while  still  providing  the  mechanisms  to  communicate  the 
same  information  across  multiple  systems. 


Both  ranges  are  using  one  integrated  tool  to  support  the  planning,  scheduling,  resource  management  and  billing 
functions  and,  because  each  one  has  defined  their  data  processes,  they  can  configure  the  tool  accordingly  and  still 
communicate  and  collaborate  using  a  different  implementation  of  the  same  tool. 

Lines  represent  information  exchange 


Figure  3-2.  A  conceptual  view  of  range  operations  supported  by  a  configurable, 
integrated  tool. 

There  are  many  initiatives  under  way,  both  commercial  and  government-funded,  that  are 
concentrating  on  the  development  of  architectures  and  integration  mechanisms  that  would  be 
required  to  make  this  concept  a  common,  everyday  reality.  However,  for  the  ranges  to  embrace 
this  concept  they  would  have  to  define  a  common  business  framework.  This  type  of  model 
would  allow  them  to  share  information  and  resources  and  to  inter-operate  on  an  as  needed  basis 
while  continuing  to  support  their  customers  to  achieve  their  unique  test  and  training  goals. 

3.2  Recommended  Approach 

3.2.1  Model  Template.  Define  a  model  template  that  will  fit  the  broad  spectrum  but  allow  for 
uniqueness  where  necessary.  Users  must  define  the  categories  and  the  levels  of  configuration 
that  would  allow  a  tool  to  be  both  expandable  in  functionality  and  flexible  in  its  design.  For 
example,  a  range  could  choose  to  only  deploy  the  functionality  that  allows  for  scheduling  and 
continue  using  other  tools  for  planning  and  execution.  Or,  a  range  could  choose  to  deploy  the 
same  configuration  of  functionality  with  a  different  user  interface.  This  form  of  system  design  is 
becoming  the  approach  of  choice  by  leading  software  and  system  developers  as  it  allows  a  wider 
user  population  to  benefit.  This  approach  would  allow  specific  ranges  to  preserve  uniqueness 
when  necessary  to  ensure  the  success  of  their  operations. 
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3.2.2  Software  Design.  Concentrate  on  configurable  software  design  and  distributed 
implementation  where  applicable.  Current  technology  allows  the  system  designer  to  build  and 
deploy  software  in  a  modular  fashion.  The  ranges  could  benefit  from  modular  design  in  two 
significant  ways:  (a)  by  sharing  development  and  maintenance  costs  and  (b)  by  improving  the 
ability  to  communicate  and  transfer  information  among  the  range  community. 

3.2.3  Core  Requirements.  Create  consensus  and  detennine  what  are  the  core  requirements  that 
would  best  support  range  operations.  The  following  points  should  be  thoroughly  studied  by  all 
potential  stakeholders,  and  a  decision  should  be  made  as  to  what  levels  of  commonality, 
automation,  and  maintenance  jurisdiction  are  to  be  applied  when  designing  future  system 
capabilities: 

a.  Resource  management  levels 

b.  Aggregation  of  assets  to  satisfy  the  requirements  of  an  event 

c.  Coordination  of  information  sharing  at  the  different  levels  of  range  management 

d.  Support  of  the  life-cycle  operations  of  a  range  event  (from  planning  &  scheduling,  to 
post-operations  support) 

e.  Support  planning  and  simulation  for  feasibility  of  range  events  and  optimization  of  range 
resource  management 

3.2.4  Management  Support.  Provide  the  right  project  management  support  with  the  right 
combination  of  technical  and  operational  direction  and  control.  The  multiple  number  of  end 
users  for  a  Range  Resource  Management  and  Scheduling  capability  dictate  that  representatives 
of  all  functions  agree  on  the  functionality  that  would  be  provided  by  the  tool.  Furthermore,  a 
facilitator  should  be  used  during  the  design  of  the  tool  to  ensure  that  all  stakeholders’  views  are 
adequately  represented. 

3.2.5  Commonality  Features.  Detennine  how  commonality,  sharing  of  assets,  inter/intra -range 
operations  relate  to  the  design  and  deployment  of  future  range  systems: 

a.  Investigate  how  investment  in  new  range  systems  could  influence  commonality  of 
systems  lifecycle. 

b.  Determine  how  the  DoD  Business  Initiative  Council  and  Foundation  Initiative  2010 
relate  to  future  range  resource  and  scheduling  capabilities. 

c.  Clearly  state  where  new  common  processes  will  be  institutionalized,  where  local 
governing  procedures  will  be  followed,  and  how  it  all  fits  into  the  range  environment  of 
the  future. 

3.2.6  Emerging  Technologies.  Investigate  the  feasibility  of  emerging  technologies  such  as: 

a.  Web  applications  such  as  Semantic  Web  that  allow  sharing  of  content  across  the  specific 
communities  while  matching  content  to  a  specific  user’s  profile.  Figure  3-3  illustrates 
how  the  ranges  could  reap  the  benefits  from  the  use  of  the  web-enabled  applications. 
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b.  The  extended  Markup  Language  (XML),  which  would  help  define  multiple 
configurations  of  data  and  services 

c.  Simple  Object  Application  Protocol  (SOAP)  to  help  with  the  exchange  of  data 
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Purpose 

Type  of 
Application 

Description 

information 

Dissemination 

Web 

Publishing 

Web  publishing  applications  could  concentrate  on  the 
static  publishing  of  large  volumes  of  information  for  the 
range  user  community  such  as  range  capabilities,  general 
information  or  points  of  contact  data. 

Collaboration 

and 

Knowledge 

Sharing 

Intranet 

Application 

Internally  focused,  these  sites  could  allow  range  support 
personnel  to  collaborate  and  share  common  information 
about  range  resources,  upcoming  events,  and  workflow 
management. 

Self-service 
Components  or 
Applications 

Content-driven 

Business 

These  sites  could  offer  a  variety  of  services  for  both  the 
range  community  and  its  customers.  Applications  could 
be  invoked,  as  they  are  needed,  by  the  end-user.  For 
example,  a  range  user  could  use  this  type  of  application  to 
generate  detailed  information  about  the  program  including 
scheduling  data,  cost,  or  range  instrumentation  reliability. 

Comprehensive 
e-Range  Sites 

Portal 

Applications 

These  implementations  follow  the  same  self-service 
mantra  (content,  business,  community)  and  could  offer  a 
personalized  web  experience  based  on  a  user  profile  that 
is  activated  with  the  user’s  login.  In  addition,  portal 
applications  could  provide  up-to-date  content  and 
seamless  access  to  a  number  of  different  service  modules 
or  advanced  capabilities  that  are  stored  in  a  user’s  profile. 

Figure  3-3.  A  conceptual  view  of  web  applications  for  the  range  community. 


3.2.7  Design  Considerations.  Engage  in  a  phased  development  approach  that  would  foster  the 
model-test-deploy  methodology.  Develop  and  test  with  end-users  all  prototype  designs  of 
functionality  and  interfaces  early  in  the  design  stage.  With  the  rapid  change  of  technology 
platforms  and  techniques,  it  would  be  advisable  not  to  engage  in  long-tenn  development  projects 
that  would  yield  results  almost  obsolete  by  the  time  they  reach  the  end-user.  It  is  recommended 
that  the  designers  and  developers  share  a  constant  awareness  of  new  developments  in  technology 
and  reflect  those  in  the  development  and  implementation  of  the  final  capability. 


3-4 


